Messaging, as discussed here, may be defined as a method that allows two entities to communicate by sending and receiving messages without requiring human interaction. One of the most important aspects of messaging is its asynchronous nature: the sender of the message does not need to wait for the recipient to receive the information. Sending applications are free to generate messages at an appropriate speed, handling peak periods as they occur, without having to wait for recipients to deal with the requests.
Messaging methods vary in their implementations. Two of the most common implementations are the hub-and-spoke architecture and the bus architecture.
In the hub-and-spoke architecture, applications are connected to a central processor, which may be called a message server. The message server handles all communication among the connected applications, which are called the application clients. An application client can be a sender of a message, a recipient, or both.
The message server is responsible for routing messages correctly, authenticating and authorizing user access, and guaranteeing the delivery of messages.
A bus architecture does not have a centralized message server to coordinate the distribution of messages. Instead, each application client includes the functionality typically found in a message server. Application clients are connected to a message bus, which typically uses the network layer of the IP multicast protocol. Although the multicast network layer routes messages among each of the application clients, the clients must perform all checks and balances to ensure that the messages are delivered securely and reliably.
One of the major problems of today's messaging methods concerns the execution of related requests in a parallel execution environment. In FIG. 1, clients 10A-10N send messages to execution systems 17A and 17B through a message queue 14. For example, a client sends a payment message request to a bank. If the client sends another related request immediately following the payment request, e.g., to modify or cancel the payment request, the messaging method must always preserve the order of the original sequence of requests to guarantee a consistent execution. In a sequential execution environment there is no problem, since all requests are executed according to their original sequence.
In a parallel execution environment, however, e.g., an environment where the target system has two or more processors, preservation of the context-based sequence cannot be guaranteed. The parallel execution system starts a new thread for each incoming message request and executes requests without regard to their intended order. This may transpose the execution of two consecutive requests that are related. For example, a request to cancel a payment request may be executed before the payment request itself. Here, the request to cancel the payment request fails because there is nothing to cancel at the time the cancellation is executed, and the payment subsequently goes through despite its intended cancellation.
Existing messaging systems, for example the IBM MQ Series, do not provide any functionality for processing context-based requests in parallel execution environments without human interaction.
Thus, there is a need to provide an improved messaging system and method which is applicable in a parallel execution environment and which guarantees the automatic execution of related requests according their context-based or original sequence, without requiring human interaction.